- C3: keep the `JniType(string)` overload but rewrite the comment to
  explain exactly why — its `TryFindClass(string, bool)` path falls back
  to `Class.forName(name, true, info.Runtime.ClassLoader)`, which
  resolves via the runtime's app ClassLoader (the one that loaded
  `mono.android.Runtime` from the APK). The `ReadOnlySpan<byte>`
  overload only calls raw `FindClass` and would resolve via the
  system ClassLoader, returning a different `Class` instance.
- C7: restore `OnRegisterNatives` visibility from `internal static`
  back to `static` (private). There are no in-repo callers.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- C2: emit generic-definition proxies deriving from the non-generic
  `JavaPeerProxy` base (3-arg ctor: `string jniName, Type targetType,
  Type? invokerType`) instead of `JavaPeerProxy<Java.Lang.Object>`.
  Concrete-target proxies still use `JavaPeerProxy<T>` (2-arg ctor).
  `EmitTypeReferences` was renamed accordingly and the `.ctor` body
  now pushes `targetTypeRef` via `ldtoken`/`GetTypeFromHandle` when
  emitting against the non-generic base.
  The skip was defensive because the old generic proxy emit failed at
  load; with C2 in place the proxy loads cleanly, so generic
  definitions can get `[TypeMapAssociation]` entries again. Added a
  regression test (`Fixture_GenericHolder_HasAssociation`).
- C8: relax `Generate_ProxyType_IsSelfAppliedAsCustomAttribute` to
  accept both `MemberReference` (parent is the proxy `TypeDefinition`)
  and `MethodDefinition` whose declaring type is the proxy. Also relax
  `Generate_ProxyType_UsesGenericJavaPeerProxyBase` to allow
  `HandleKind.TypeReference` for open-generic proxies now that they
  inherit from the non-generic base.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Investigated the suggestion to drop the lazy `__md_registerNatives()`
emission for `CannotRegisterInStaticConstructor` types (Application +
Instrumentation subtypes). Conclusion: we keep it, and the comment has
been updated to explain the ordering constraint that makes it
necessary.

`ApplicationRegistration.registerApplications()` is invoked from
`MonoPackageManager.LoadApplication`, which runs from
`MonoRuntimeProvider.attachInfo`. But `Application.attachBaseContext`
fires *before* ContentProvider.attachInfo — so a user Application that
overrides `attachBaseContext` can trigger a native callback before
`registerApplications()` has run. The lazy one-time helper in each
native-method wrapper is the safety net that covers that window.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…trimmable typemap path

The legacy `_RemoveRegisterAttribute` target (in Xamarin.Android.Common.targets)
is a no-op copy step that mirrors `@(_ResolvedAssemblies)` into
`@(_ShrunkAssemblies)` at `<dir>/shrunk/<file>` paths. `ProcessAssemblies`
unconditionally rewrote `ShrunkAssemblies` to those `shrunk/` paths
whenever `PublishTrimmed && !AndroidIncludeDebugSymbols` was true.

The trimmable typemap path does not strip `[Register]` attributes and
does not need the `shrunk/` copy; the previous code papered over the
mismatch by overriding `_RemoveRegisterAttribute` to rebuild
`@(_ShrunkAssemblies)` from `@(_ResolvedAssemblies)` at that stage —
fragile and hard to follow (flagged by Copilot reviewer as C6 because
the override also dropped the `DependsOnTargets="_PrepareAssemblies"`
and the `AndroidLinkMode != 'None'` conditions from the base target).

Fix:

* Thread the `_AndroidTypeMapImplementation` property into
  `<ProcessAssemblies>` via a new `AndroidTypeMapImplementation`
  string input.
* Skip the `shrunk/` path rewrite when the input is "trimmable", so
  `ShrunkAssemblies` is simply `OutputAssemblies` for that path.
* Reduce the trimmable override of `_RemoveRegisterAttribute` to an
  empty target — the base target's copy is no longer needed because
  `@(_ShrunkAssemblies) == @(_ResolvedAssemblies)` already.

C6 is resolved as a side effect: there is no longer any target body
that could depend on `_PrepareAssemblies` or the linker conditions.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The typemap generator emits one TypeMapAssociation per generic peer, keyed
by the open generic definition (e.g. typeof(JavaList<>)). The CLR
TypeMapping dictionary does identity-based lookups (see dotnet/runtime's
TypeMapLazyDictionary.cs), so closed instantiations such as
typeof(JavaList<string>) never match the registered open entry directly.
Previously GetProxyForManagedType did a single TryGetValue on that
dictionary and silently returned null for every closed generic peer,
breaking managed→JNI name resolution for things like JavaList<string>.

- GetProxyForManagedType: after a direct miss, if the type is a closed
  generic, retry with type.GetGenericTypeDefinition(). GetGenericTypeDefinition
  is safe under AOT + full trim (it is not RequiresDynamicCode). The
  resolved proxy is cached under the original closed Type so subsequent
  lookups remain O(1).
- TryGetProxyFromHierarchy: the per-proxy TargetType for generic peers is
  the open generic definition, so targetType.IsAssignableFrom(proxy.TargetType)
  returned false when the caller hint was a closed instantiation. Extract
  a TargetTypeMatches helper that additionally accepts a hint whose base
  chain contains a closed form of the proxy's open generic definition —
  no type-argument comparison since Java erases generics and one proxy
  serves every closed instantiation.

Adds a device-side test that exercises the GTD fallback through the public
TryGetJniNameForManagedType path using JavaList<T>.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The previous commit added a single device test exercising the GTD
fallback via JavaList<T>, but that scenario only hits the direct
IsAssignableFrom branch of TargetTypeMatches (JavaList<T> erases to the
non-generic JavaList, whose proxy's TargetType is the non-generic type).
The open-generic branches of TargetTypeMatches were not exercised.

- Promote TargetTypeMatches from a local static inside GetProxyForJavaObject
  to an internal static member of TrimmableTypeMap so it can be unit-tested
  directly.
- Add pure-function tests for TargetTypeMatches covering: direct assignable,
  open generic self-match, closed subclass base-walk, deeply closed
  subclass, different open GTDs, unrelated types.
- Add regression tests for GetProxyForManagedType:
    * non-generic type still resolves directly (regression shield for the
      fast path)
    * an unknown closed generic (e.g. List<int>) misses both the direct
      and GTD lookups and returns false
    * repeated lookups of the same closed generic are idempotent, verifying
      the cache is keyed by the original closed type.

All new tests are gated on the RuntimeFeature.TrimmableTypeMap feature
switch so they are a no-op in non-trimmable configurations.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

When a generic Android binding is declared as an interface (e.g. an open
generic peer interface like IJavaCollection<T>), the proxy's TargetType is
the open interface definition. The caller's hint in GetProxyForJavaObject
is usually a closed class that implements that interface (from the
marshaller's target signature). The previous base-chain-only walk missed
this case, so the hierarchy lookup silently rejected the correct proxy.

Extend TargetTypeMatches to also scan targetType.GetInterfaces() for any
closed generic interface whose definition equals the open proxy target.
GetInterfaces() on a class also includes interfaces from its base types,
so closed subclasses of types implementing an open generic interface are
covered.

Suppress IL2070 on the helper with a justification: targetType originates
at JNI marshalling call sites where the caller's generic signature roots
the interface set. Legacy Android binding generators have always relied
on this reachability contract.

Adds unit-test coverage for:
- closed class implementing an open generic interface
- closed subclass inheriting the interface implementation
and a standalone C# program confirmed 9/9 assertions pass before committing.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The previous example implied that a hint of `IList<string>` would match a
proxy whose target is `JavaList<>`. It does not: `IList<string>.GetInterfaces()`
returns only its super-interfaces (ICollection<string>, IEnumerable<string>,
IEnumerable), and none of their generic-type-definitions equals `JavaList<>`.

The actual scenario covered by the interface walk is: the proxy target is
an **open generic interface** peer, and the hint is a closed class that
implements a closed instantiation of that interface. For a class hint,
`GetInterfaces()` enumerates every interface the class implements, so the
closed form is discovered and its GTD matches the open interface target.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Covers the case where a closed class hint does not implement any closed
form of the open generic interface that the proxy targets. Also rewrites
the positive-case comment that incorrectly described an `IList<string>`
hint matching a `JavaList<>` proxy (that scenario is not covered by the
interface walk — it would require walking the proxy's own interfaces).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Collapse the two-step "try closed, then fall back to GTD" into a single
lookup by normalising the type first. The generator never keys the proxy
typemap on a closed generic instantiation (Java erases generics, so one
open-GTD entry covers every closed form), so the first lookup in the old
code was always a miss for closed generics — remove it.

No behavior change; host tests still 355/355.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The interface walk added to `TargetTypeMatches` (via `Type.GetInterfaces()`)
required an `[UnconditionalSuppressMessage("Trimming", "IL2070", ...)]`
because `GetInterfaces()` is annotated
`[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.Interfaces)]`
on its `this` parameter, and propagating that annotation up the call chain
(`TargetTypeMatches` -> `TryGetProxyFromHierarchy` -> `GetProxyForJavaObject`
-> `JavaMarshalValueManager.CreatePeer`) would require modifying Java.Interop's
public `CreatePeer` override signature, which only carries a `Constructors`
DAM today.

Audit of the call path shows the interface walk is dead code in practice:
`TryGetProxyFromHierarchy` walks the JNI class chain only (via
`GetObjectClass` + `GetSuperclass`), never JNI interfaces, so no
open-generic *interface* proxy target ever reaches `TargetTypeMatches`
from this path. The remaining base-chain + GTD-identity logic covers every
case our generator emits.

If a future change needs to resolve proxies through a JNI interface chain,
the right answer is a generator-emitted implementer map (statically trim-safe)
rather than reflecting over `GetInterfaces()` at runtime.

Also drops the two tests and fixture types that exercised the removed
interface walk. Host unit tests: 355/355 pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>